home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9712 / 000064_owner-linux-arm…r.rutgers.edu _Thu Dec 25 19:07:42 1997.msg < prev    next >
Internet Message Format  |  1998-01-04  |  4KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id TAA08965
  4.     for <willy@odie.fluff.org>; Thu, 25 Dec 1997 19:07:38 GMT
  5. Received: from vger.rutgers.edu ([128.6.190.2]:43562 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <13574-627>; Thu, 25 Dec 1997 21:07:05 +0200
  6. Received: by vger.rutgers.edu id <970855-1477>; Thu, 25 Dec 1997 14:05:03 -0500
  7. Received: from philip@localhost (fake: stdin ("HELO localhost" ident: "uid#33108@localhost")) by vger.rutgers.edu with SMTP id <970865-1477>; Thu, 25 Dec 1997 14:04:36 -0500
  8. Date:     Thu, 25 Dec 1997 14:04:35 -0500 (EST)
  9. From: Philip Blundell <philip@vger.rutgers.edu>
  10. To: Russell King <linux@arm.uk.linux.org>
  11. cc: linux-arm@vger.rutgers.edu
  12. Subject: Re: new patch (fwd)
  13. In-Reply-To: <Pine.LNX.3.95.971225190129.987A-100000@kensington.london.uk.eu.org>
  14. Message-ID: <Pine.LNX.3.95.971225135428.1088A-100000@vger.rutgers.edu>
  15. MIME-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  18. Sender: owner-linux-arm@vger.rutgers.edu
  19. Precedence: bulk
  20. Status: RO
  21.  
  22. > No Phil.  Your patch does the following:
  23. > 
  24. > *    Changes the help descriptions for the ethernet cards.
  25.  
  26. That's true.  I hadn't particularly intended for that to leak into the
  27. patch.
  28.  
  29. > * Moves the kernel link address back to 0x1800000, which is where it was
  30. > originally. 
  31.  
  32. Yes, on your advice.
  33.  
  34. > * Changes a few #definitions to to with processor and machine type with
  35. > no overall
  36. >     effect, especially the processor definitions.
  37. >     Do you really understand the meaning of the __arm2__ __arm3__
  38. > etc *compiler*
  39. >     definitions? 
  40.  
  41. Yes.  gcc 2.8 doesn't define __arm2__ or __arm3__ if you give it the
  42. -mapcs= and -mcpu= options, so with the old #ifdefs you ended up getting
  43. support for no CPUs at all.  You do still get __arm3__ defined with -m3,
  44. but you also get complaints about this being an obsolete option.
  45.  
  46. > * Removes *all* support for the binutils currently supplied with the ARM
  47. > Linux
  48. >     distribution.
  49.  
  50. Since the support was 50% gone already, this strikes me as little
  51. hardship.  The binutils with this problem fixed has been available for
  52. months.
  53.  
  54. > *    Removes the floppy code's ARM architecture dependence.
  55.  
  56. Why, exactly, do you feel this is bad?  I'm slightly confused as to which
  57. patch you're talking about here.  The one I had last week removed the
  58. architecture dependence, and your reaction to that was "good".
  59. Unfortunately I goofed slightly and the result wouldn't compile
  60. properly (and I left out some debug stuff).  This newer patch remedies
  61. that; I don't understand your objection.
  62.  
  63. > * Slightly optimises the __xchg() function in terms of memory data
  64. > space. 
  65.  
  66. ... and, more importantly, allows you to compile armksyms.c on a5k
  67. machines.
  68.  
  69. > * Unnecessarily changes the decompressor code. 
  70. >     If your compiler can't hack that, then throw it away - it's not ANSI
  71. >     conformant, and must be broken.
  72.  
  73. It's gcc, and I don't know of any alternative.
  74.  
  75. > *    Various spelling corrections.
  76.  
  77. I can't see that they do any harm either, though I agree that the world
  78. won't end without them.
  79.  
  80. > In effect, what Phil is trying to do is to remove as many changes as
  81. > possible to the driver code that has moved from the drivers directories
  82. > to the arch/arm/drivers heirarchy. 
  83.  
  84. That's true, and last time I posted a patch to do this you were all in
  85. favour. 
  86.  
  87. > What is the point in reversing some of the changes made to *improve* the
  88. > performance of the 2.0 kernels when we're moving towards the 2.1
  89. > kernels? 
  90.  
  91. Because the fewer gratuitous changes we have, the less work there is to do
  92. with the merge.  If you want to fix 8390.c to go faster, then since it's
  93. not an ARM specific change there's no need to make another copy of the
  94. file.
  95.  
  96. > There have been *no* bug fixes in this patch whatsoever, in fact, there
  97.  
  98. If that's your opinion, fine.  Merry Christmas, by the way.
  99.  
  100. p.
  101.  
  102.  
  103. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu